Cumulative content of Working Group Meetings in 2025
Date: 13/02/2025
Participants: Peter Borresen, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
ResponseStatus codelist was put at the level of AbstractContainer as seen on the diagram below:
-
Further Questions regarding the fields of the Receipt advice data model were answered.
There was a further discussion with the ESPD team regarding ticket https://github.com/OP-TED/ESPD-EDM/issues/413:
-
Add a Github Issue about renaming that highlighted property seen in the diagram above in order to cover for the parts mentionerd in the https://github.com/OP-TED/ESPD-EDM/issues/413 depicted in the figures below. A possible name could be
epo:canProvideEvidenceAlso the attribute coversAllSelectionCriteria should be at the level of the evidence.
Action Points
-
Create a Github Issue to implement Object Line Identifier with the predicate SalesOrderLineID.
-
Add a Github Issue about renaming that highlighted property mentioned above.
WG meeting
Date: 11/02/2025
Participants: Natalie Muric, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis
Discussions
A new definition for the epo-sub:ESPD was given according to the diagram below:
Issue #734 was updated accordingly, and epo-sub:ESPD and ePO-acc:ESPDRequest: were updated accordingly.
The WG started discussing about the ORSD for the eAwarding module.
ESPD-EDM https://github.com/OP-TED/ESPD-EDM/issues/423 and https://github.com/OP-TED/ESPD-EDM/issues/413 issues were discussed:
-
#423:
-
eForms and UBL are not aligned, ESPD is aligned with UBL.
-
A qualifying party has a codelist that describes the role. So ESPD is covered by this. 423 can thus be closed.
-
-
#413
-
It was discussed that although the specific field mentioned in issue #413 covers multiple lists or equivalent certificates, in the ePO there are no Lists.
-
It was mentioned that the information conveyed by that specific field is not used as an evidence for any criterion and that it should be modelled as additional information and not evidence.
-
Working Group Meeting
Date:30/01/2025
Participants: Peter Borresen, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Alignment with PEPPOL for eFulfilment #569.
Discussion
-
Alignment with PEPPOL for eFulfilment #569.
-
Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.
-
Action Points
-
Create a Github Issue: Harmonize all post award document classes such as despatch advise to use
The epo:associatedWith rather than a direct link to an epo:Document.
Also add a link from the lines to a document.
-
Create a ticket This at-voc-new:RespoonseStatus should be renamed and aligned with https://docs.peppol.eu/logistics/2024-Q1/codelist/UNCL4343_T128/
Working Group Meeting
Date: 28/01/2025
Participants: Victorio Bentivogli, Paul Donohoe, Ioannis Fountoukidis, Yves Jordan, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
Discussions
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
During the meeting, definitions for the following BTs that appearon the Annex of Regulation 2023/2884:
-
BT-776 did not have any impact on the Ontology.
-
BT-810
-
Is the indicator attribute epo:isCompliantToEnergyEfficiencyDirective needed? It was decided that this indicator will not be modelled since if it is true we will have an instance of epo:EnergyEfficiencyInformation.
-
-
BT-811
-
Two code lists are needed:
-
Energy-efficiency-Item (already in ePO)
-
Energy-efficiency-Basis (not in ePO)
-
-
As a result, at-voc:energy-efficiency-basis was created, and linked to epo:EnergyEfficiencyInformation. (see diagram below).
-
-
Create two diagrams in ePO (1 for competiton and 1 for Lot-result) for epo:EnergyEfficiencyInformation class.
-
813 and 814 are paired.
-
BT-814 :
-
It was discussed that this will be implemented with the SDK implementation., not with the Regulation 2023/2884.
-
Two predicates connecting epo:EnergyEfficiencyInformation to epo:Quantity will be epo:hasConcumptionQuantity and epo:hasSavingsQuantity.
-
The guides/gde_004_eed.pdf · main · eProcurement Group / eForms Group / Docs · GitLab Guide was consulted.
-
At the level of epo:EnergyEfficiencyInformation we will have epo:EnergyEfficiencyItem.
-
Working Group Meeting
Date: 23/01/2025
Participants: Peter Borresen, Paul Donohoe, Yves Jordan
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
eFulfilment meeting regarding Receipt Advice.
-
Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]
-
Phttps://github.com/OP-TED/ePO/issues/529[otential problem with modelling of epo:Period ]ePO #529
-
Mapping of at-voc:timeperiod to the OWL Time Ontology ePO #681
Discussions
During the first part of the WGM, eFulfilment and specifically Receipt Advice was discussed: Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.
Regarding the “Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]” github issue:
-
Regarding the following fields: Τhey are just for T02 and are about a Tender, so they should be put in a class on the level of epo:TenderAwardOutcome. This class should be named epo:TenderAwardOutcomeInformation. Another class: epo:ContractCondition was added.
-
OPP-080-Tender: Kilometers Public Transport: Represented as a predicate to the epo:Quantity class.
-
OPP-035-Tender: Revenues Allocation of tickets sales code uses the following codelist With only one value.
-
OPP-032-Tender: Revenues Allocation: Add epo:hasTicketsSalesRevenueAllocation xsd:decimal, [0..1] attribute on epo:TenderAwardOutcomeInformation.
-
OPP-030-Tender: Contract conditions Code: uses the following codelist.
-
OPP-031-Tender: Contract Conditions Description (other than revenue allocation): epo:hasContractConditionsDescription rdf:plainLiteral. [0..1] attribute on epo:ContractConditio.n
-
OPP-033-Tender: Penalties and Rewards Code: has only one value (found here). Not going to implement.
-
OPP-034-Tender: Penalties and Rewards Description: epo:hasPenaltiesAndRewardsDescription rdf:plainLiteral [0..1] attribute to to epo:TenderAwardOutcomeInformation.
-
-
BT-127-Notice:No modification will happen for now.
Action Points
-
Create a Github issue: For the Receipt Advice ePO diagram: To represent the action-code and reject-reasons codelists also at the level of the epo-ful:ReceiptAdvice.
Working Group Meeting
Date: 21/01/2025
Participants: Paul Donohoe, Yves Jordan, Dragos Stoica
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726
Discussions
Regarding Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726:
Regarding OPT-070-Lot: * An example of a Call For Expressions Of Interest document was presented (F_CEI_EN_DRAFT_2019-03-25.pdf). The ePO team used the document to create a CM diagram for Call For Expressions Of Interest. * The latest Notice-types.json eforms document was consulted. * Class epo-not:PINTransportationNotice was created as seen on the diagram below.
-
Class epo-not:CANTransportationNotice was created as seen on the diagram below.
-
It appears that class epo-not:CallForExpressionOfInterest was already implemented in the ePO as epo-not:NoticeCEI. To discuss the removal of epo-not:CallForExpressionOfInterest in a future WGM.
Regarding OPT-071-Lot :
-
The Customer-service codelist was found and does not currently exist in ePO and will be added.
-
It was mentioned that For T02 and T01, epo:LotGroup is Forbidden
*Class epo:QualityTargetInformation was created; it should always be linked to an epo:ContractTerm.
* at-voc:customer-service was created on the level of epo:QualityTargetInformation. They are both mandatory.
* Attribute epo:hasQualityTargetDescription was created.
Regarding Assets in a Contract: (they are all for T02):
-
OPP-020-Contract: Assets related contract extension indicator. Class epo:Asset was created.
-
OPP-021-Contract: Used asset Added dct:description [0..1] for epo:Asset.
-
OPP-022-Contract: Significance (%): Added attribute epo:hasSignificance rdf:PlainLiteral. To be further discussed as concept name may change in the future
-
OPP-023-Contract: Predominance (%): Added attribute epo:hasPredominance rdf:PlainLiteral. To be further discussed as concept name may change in the future
Contract terms and other information of a Tender: These are all T02 Notices. It was decided that the WGM will work on the above fields next WGM on 23/01/2025.
OPP-040-Procedure: Main Nature - Sub Type: at-voc:transport-service was created.
Action Points
-
EPO team to look at the F_CEI_EN_DRAFT_2019-03-25.pdf
-
Document and Investigate actual T01,T02 and CEI Notices to confirm that the new ePO diagrams including attribute types are correct.
-
To discuss the removal of epo-not:CallForExpressionOfInterest Class on 28/01/2025 WGM.
Working Group Meeting
Date: 16/01/2025
Participants: Peter Borresen, Paul Donohoe, Yves Jordan, Natalie Muric, Dragos Stoica,
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Agenda
-
Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726
-
Alignment with PEPPOL for eFulfilment #569.
-
Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691
-
Potential problem with modelling of epo:Period #529
-
Mapping of at-voc:timeperiod to the OWL Time Ontology #681
Discussions
Regarding the alignment with PEPPOL for eFulfilment #569, it was decided that the alignment between PEPPOL business term requirements and ePO eFulfilment module will continue with the Receipt Advice Data model.
Regarding the new BTs described in Regulation 2023/2884 to ePO concepts.https://github.com/OP-TED/ePO/issues/691[#691:]
-
BT-749: It was discussed that although BT-749 was removed from the regulation, no removal of an ePO concept was needed.
-
BT-681: An attribute for epo:ProcurementElement was added for this. epo:appliesForeignSubsidiesRegulation xsd:boolean[0..1]
-
BT-682 should be implemented as the foreign Subsidy Measure Conclusion vocabulary connected to Class epo:TenderAwardOutcome as a codelist, using the predicate epo:specifiesForeignSubsidiesMeasureConclusion.
-
A use-case is required to find out in what procurement phase should this codelist be used. This will be done in the future as part of describing the Procurement Process. A link to the Digigrow guide on how to use this codelist was provided: https://code.europa.eu/eproc/eforms/docs/-/blob/main/guides/gde_001_fsr.md?ref_type=heads
-
BT-684: It was decided that this BT will not be implemented for now.
-
BT-681 : Should points to epo:LotAwardOutcome. .
-
BT-685 is for the Tender. There is currently no codelist for this. It should go directly to the epo:LotAwardOutcome class. (via the epo:InternationalProcurementInstrumentMeasuresInformation Class seen in the diagram below)
-
BT-686 : Attribute epo:hasNumberOfTendersConcerned as seen in the diagram below.
-
BT-687 : at-voc:international-procurement-instrument-application As seen in the diagram below.
-
BT-688 :Attribute epo:hasPublicInterestExceptionJustification as seen in the diagram below.
-
The International Procurement Instrument Application vocabulary was consulted. It was mentioned that the Digigrow guide (link above) better explains the above mentioned BTs.
The epo:InternationalProcurementInstrumentMeasuresInformation Class
-
It is important to note that these IPIs are for third world countries or Tenders that have third country subsidiaries.
Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726
-
Lot tenderingTerms Fields were discussed:
-
OPT-070-Lot : Class epo:CallForExpressionOfInterest is a typeOf epo:Notice.
-
Working Group Meeting
Date: 14/01/2025
Participants: Paul Donohoe, Yves Jordan, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis
Discussions
Regarding #726
-
The following IDs are mandatory in UBL but not required in eForms, so there is no need to map them to ePO either for Lot or Part:
-
OPT-111
-
OPT-112
-
OPT-113
-
-
The following Classes were implemented: (also depicted on the diagram below) For the following fields:
-
OPT-110-Lot-FiscalLegis
-
OPT-110-Part-FiscalLegis
-
OPT-120-Lot-FiscalLegis
-
OPT-120-Part-FiscalLegis
-
OPT-130-Lot-FiscalLegis
-
OPT-130-Part-FiscalLegis
-
epo:LegislativeDocumentation
-
epo:FiscalLegalDocumentation
-
epo:EnvironmentalLegalDocumentation
-
epo:EmploymentLegalDocumentation
-
epo:Class epo:Documentation was created that is a generalisation of the above Documentation classes.
-
Predicate providesDocumentation was added fromTaxInformationProvider to epo:Documentation
-
-
-
ΒG-700 was mapped to epo:QualificationCriterion.
-
ΒT-806: The codelist used is in eForms (exclusion-grounds-source) and it has 3 values: epo-notice, epo-sub-espd (this might be epo-acc-espd) and epo-procurement-document. We will create 3 attributes at the level of epo:QualificationCriteria for each value:
-
epo:hasQualificationCriteriaStatedinNotice
-
epo:hasQualificationCriteriaStatedinESPDRequest
-
epo:hasQualificationCriteriaStatedinProcurementDocuments.
-
-
BT-821: uses the same codelist as BT-806.
-
BT-67(a), BT-77(b): epo:hasExclusionGroundType predicate connected to at-voc:exclusion-ground was added.
-
BT-748 At-voc:usage will not be used anymore. Instead we create predicates epo:doesNotRequireSelectionCriterionType epo:hasUnknownUsageOfSelectionCriterionType connected to at-voc:selection-criterion codelist. that will be used in case a specific selection criterion is not used or is not yet known.
-
